The purpose of this change is to document the architecture of the
openstack-armada-app repository, explaining what each folder is
responsible for / what it does. It also adds the HACKING.rst and
CONTRIBUTING.rst, which are already present at other repositories.
Test Plan:
PASS - Verify that the rst files are properly loaded
Story: 2011059
Task: 49669
Change-Id: Id2c8273cb8fbe5c77eced8f9a3a7727002c322ba
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
After applying STX-Openstack, some API pods are failing to pass the
readiness probe. This change adds a initialDelaySeconds value to the
deployment files of the services that are having this warning.
The liveness probe for these deployments already have a
initialDelaySeconds of 30 seconds, adding this value to the readiness
probe supresses this issue.
For the glance-api deployment, it was also required to add the
initialDelaySeconds to the liveness probe.
A review was proposed to the upstream openstack-helm repository [1], and
is currently under review. If the change is merged, this patch can be
ignored on future STX-Openstack development.
[1] https://review.opendev.org/c/openstack/openstack-helm/+/911015
Test Plan:
PASS: Build openstack-helm package
PASS: Build STX-Openstack application tarball
PASS: Upload / apply STX-Openstack application
PASS: Check the cinder-api, glance-api and heat-api pods and verify that
there are no more readiness probe failures.
Closes-Bug: 2030908
Change-Id: If273f095ae0c589fa71faff7756d5f6861cfd264
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
Now that stx-openstack application is more up-to-date with OpenStack
releases timeline, using "stable/<release>" git references is not
advised since such branches can receive fixes cherry-picks on upstream
repos and therefore make our stx-* images build not fixed to a given
source code version [1].
This change sets all upstream repos references to commits SHAs, as per
of today 2024 Feb 16th, so StarlingX release 9.0 will have a stable and
reproducible build.
If there is the need of cherry-picking any OpenStack upstream fix, this
should be handled by a specific task/launchpad later (on StarlingX
master branch).
With the commit SHAs aligned, application release info can be set to
StarlingX 9.0 release (as peer other applications).
[1] https://bugs.launchpad.net/starlingx/+bug/2052644
Story: 2010715
Task: 49588
TEST PLAN:
PASS: build-helm-charts.sh --os debian
--package stx-openstack-helm-fluxcd
--app stx-openstack
PASS: build-wheel-tarball.sh --keep-image
PASS: build-stx-images.sh --only stx-aodh,stx-ironic,stx-barbican,
stx-ceilometer,stx-cinder,stx-glance,stx-heat,stx-horizon,
stx-keystone,stx-neutron,stx-nova,stx-placement
Change-Id: Id1cf2cbd49f0b2b5fb7d02524794310d92be8f22
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
When the app.starlingx.io/component label was added to pods it was
decided that it would be controlled by a values.yaml key
labels:isApplication and its default value was set to "false" [1]
and [2]. This should be changed to "true" since all pods created by
the stx-openstack charts are related to the stx-openstack app.
Additionally, according to LP #2052539 this new label was mixing memory
usage metrics and wrongly triggering platform alarms for "Memory
threshold exceeded".
[1] https://review.opendev.org/c/starlingx/openstack-armada-app/+/903918
[2] https://review.opendev.org/c/starlingx/openstack-armada-app/+/904128
TEST PLAN:
PASS - Build openstack-helm package
PASS - Build openstack-helm-infra package
PASS - Build stx-openstack application tarball
PASS - Upload/Apply stx-openstack application (AIO-DX)
PASS - No alarms triggered after application is applied
Closes-Bug: 2052539
Change-Id: I6e3e99b48c65d6c1730eca2f85b9d700dd6b1ef9
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
Commit [1] removed the `files` directory for both openstack-helm and
openstack-helm-infra folders, as they were not used by the Debian build
system. However, 3 files were incorrectly removed, causing issues when
running the downloader command.
This commit reintroduces these files, making sure the build for both
packages work.
[1] https://review.opendev.org/c/starlingx/openstack-armada-app/+/908177
Test Plan:
PASS - Successfully run downloader -s -b -B std,rt
Closes-Bug: 2052709
Change-Id: I4ee8d11b4c4fc78d570c4ef0f8a9d950dc748aa8
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
Add the supported minimum Kubernetes version into the application
metadata file.
The minimum Kubernetes version is set to 1.24.4 and should be changed
accordingly for future application updates.
The "supported_k8s_version:minimum" field is optional but it will become
mandatory as specified by task 49538 from this same story.
This also contains a fix to properly trigger the Tox metadata checks.
Test Plan
PASS: build-pkgs && build-image
PASS: Apply application
Story: 2010929
Task: 49544
Change-Id: I4370abf5839bb01a0fd1a62cb5cbbd2320d64166
Signed-off-by: Igor Soares <Igor.PiresSoares@windriver.com>
The `files` directory was used by the CentOS build system to grab
StarlingX-specific patches, which was deprecated in favor of
`debian/patches`, so these files are unused and safe to remove.
Test Plan:
PASS: Build openstack-helm, openstack-helm-infra
Story: 2010072
Task: 49539
Change-Id: I58edae6a02ed23a5fb6d77cf4a6cdec9c1798b15
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
Add the label app.starlingx.io/component to the pods via patches
for the openstack-helm and openstack-helm-infra repositories and
allow the value to be updated via "system helm-override-update".
This change also ensures that when changing the label value and
reapplying the app, the pod is restarted.
The value of the label can only be "platform" or "application", if
the value is different from that, the label will not be applied.
By default, all pods start with the value platform.
Test Plan:
PASS: build-pkgs -c -p openstack-helm
PASS: build-pkgs -c -p openstack-helm-infra
PASS: build-pkgs -c -p stx-OpenStack-helm-fluxcd
PASS: upload/apply/remove/delete stx-openstack
PASS: Install stx-openstack and check if pods have the label
'app.starlingx.io/component' with the value 'platform'.
PASS: After updating the isApplication variable to true for
ingress chart using "system update-helm-override" and reapplying
stx-openstack, the pods were restarted and the label was
successfully changed.
PASS: After updating the isApplication variable to true for
cinder chart using "system update-helm-override" and reapplying
stx-openstack, the pods were restarted and the label was
successfully changed.
PASS: If "isApplication" is updated with a value other than
true or false, the label on the pods "app.starlingx.io/component"
will not change.
Story: 2010612
Task: 49299
Change-Id: Ifb6e43e15e19e5b17aefd9c5b611d65b7543ded0
Signed-off-by: David Bastos <david.barbosabastos@windriver.com>
Add the label app.starlingx.io/component to the pods and allow the
value to be updated via "system helm-override-update". This change
also ensures that when changing the label value and reapplying the
app, the pod is restarted.
The value of the label can only be "platform" or "application", if
the value is different from that, the label will not be applied.
By default, all pods start with the value platform.
Patches for the openstack-helm and openstack-helm-infra
repositories with the same purpose will be created later.
Test Plan:
PASS: upload/apply/remove/delete/update stx-openstack
PASS: Install stx-openstack and check if pods have the label
'app.starlingx.io/component' with the value 'platform'.
PASS: After updating the isApplication variable to true for
nova-api-proxy chart using "system update-helm-override" and
reapplying stx-openstack, the pods were restarted and the label
was successfully changed.
PASS: If "isApplication" is updated with a value other than
true or false, the label on the pods "app.starlingx.io/component"
will not change.
Story: 2010612
Task: 49294
Change-Id: I984be94a42cc302357d0b2202be1425e80a52505
Signed-off-by: David Barbosa Bastos <david.barbosabastos@windriver.com>
Modify code to conform to flake8 and pylint.
Jobs are now flake8, pylint, py39 and metadata.
Test Plan
PASS - All zuul jobs pass as expected.
Story: 2010929
Task: 49277
Change-Id: I8144587f90760dbd976ea70216aa8d952a0c4fba
Signed-off-by: Reed, Joshua <Joshua.Reed@windriver.com>
After upgrading the OpenStack services to its 2023.1 (Antelope) release,
the RBAC policies used for test also required several updates, mainly
due to:
* Deprecated policies
* Policies that were split for more fine grained control
* Policies that had its default rule modified
* openstack-client errors that now include the 403 Forbidden when
blocking a given user
Also it was noticed that the project_read_only user was not able to list
servers (servers:detail,servers:index and servers:show).
This would cause several other failures, and we assume that this is a
default behavior that changed from Ussuri to 2023.1.
So the actual "projectreadonly_required" role key was added to be used
for policies that should be allowed to the read_only user.
Story: 2010715
Task: 49259
TEST PLAN:
PASS - Apply new enhanced RBAC policies YAML files
* system helm-override-update
PASS - Proceed with the documentation steps for configuring users
PASS - Ensure polices are working as expected (250 automated TCs)
Change-Id: Ia6036b2be694c27f6cc7ca2fded40f32862eca85
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
Aiming for the stx-openstack application hardening, this change
implements the plugin logic to gather the number of available compute
nodes and, for anything that is not an AIO-SX deployment, configure the
neutron dhcp_agents_per_network count accordingly [1].
When only two computes are available this config is set to 2, whenever
three or more compute nodes are available this config is set to 3.
There are scenarios in which the compute node fails and if it is hosting
the DHCP agent for a given openstack network, VMs on that VM won't be
able to receive DHCPOFFER and fail to receive ip and ping.
Partial-Bug: 2030883
[1] https://docs.openstack.org/neutron/latest/admin/config-dhcp-ha.html#enabling-dhcp-high-availability-by-default
TEST PLAN:
PASS - Build plugins (k8sapp_openstack)
PASS - Build stx-openstack helm charts
PASS - Apply stx-openstack and verify the Neutron config
* Check dhcp_agents_per_network count:
/etc/neutron/neutron.conf
- AIO-SX = 1
- AIO-DX = 2
PASS - Execute stx-openstack sanity tests locally
Change-Id: I6f32ac8a1706467be0be67920a3a750bb7c6b01e
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
The change [1] updates the version of the libpython2.7-minimal,
libpython2.7-stdlib, python2.7 and python2.7-minimal packages, which
caused the build for the stx-openstackclients image to fail, as it
requires the `python-dev` package [2].
Since Python 2 is not used by any Openstack project anymore, this
package wasn't doing anything, so it's safe to upgrade it to the Python
3 version of the same package. This not only solves the build issue but
keeps the image coherent due to the reason mentioned in the beginning of
this paragraph.
[1] 55eebf2d6a
[2] https://opendev.org/starlingx/openstack-armada-app/src/branch/master/upstream/openstack/python-openstackclient/debian/stx-openstackclient.stable_docker_image#L17
Test Plan:
PASS: Build stx-debian base image
PASS: Build stx-openstackclients image
PASS: Upload / apply stx-openstack
PASS: Manually upload built image to the system's registry and perform
helm-override to use it in the clients containers
PASS: Issue Openstack commands for all CLIs and verify they're working:
Cinder, Glance, Heat, Neutron, Nova and Openstack
Closes-Bug: 2043390
Change-Id: Id8d3b3572eefd7e8b0cdbd4b8c3129728647ede7
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
Since we started using Openstack Antelope, it was noticed that, when
creating backups using the Openstack CLI and specifying the `--location`
parameter, the backups would always fail with the error message:
"Backup driver reported an error: Multidriver is set but a backup
driver wasn't provided." This error was caused because, even though
patch 0002 introduced the `--location` parameter to the CLI, it was not
passing it through to the Cinder API.
This change fixes that by passing the location parameter on the backup
creation, when using the Openstack CLI.
Test Plan:
PASS: Build stx-openstackclients image
PASS: Upload / apply stx-openstack
PASS: Manually upload built image to the system's registry and perform
helm-override to use it in the clients containers
PASS: Create a Cinder volume, and boot a VM from it
PASS: Create a backup using the Openstack CLI, and passing the
`--location` parameter
PASS: Remove / delete stx-openstack
Closes-Bug: 2043383
Change-Id: Ie6f8756e3c647d2191489e298e3ea138f32c30d4
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
OpenStack 2023.1 (Antelope) introduced this issue [1][2] when
live-migrating instances, in which Nova uses getCapabilities() to
determine the host CPU model but use the model from the
domCapabilities for the guest VM using host-model [3].
According to the libvirt maintainers nova should never use
getCapabilities for anything any more.
A solution for this issue is being developed in main branch [4], but
taken as a medium priority since there is a workaround config option
already available [5] to avoid this situation.
Setting "skip_cpu_compare_on_dest" to True will, during live
migration, skip comparing guest CPU with the destination host.
When using QEMU >= 2.9 and libvirt >= 4.4.0, libvirt will do the
correct thing with respect to checking CPU compatibility on the
destination host during live migration.
StarlingX currently delivers QEMU 5.2 and stx-openstack uses a libvirt
on 7.0.0-3, therefore this can be safely used as part of our default
nova configuration updates.
[1] https://bugs.launchpad.net/nova/+bug/2023035
[2] https://bugs.launchpad.net/nova/+bug/2039803
[3] https://review.opendev.org/q/topic:fix_compareCPU_usage
[4] https://review.opendev.org/c/openstack/nova/+/899185
[5] https://docs.openstack.org/nova/latest/configuration/config.html#skip_cpu_compare_on_dest
Closes-bug: 2007303
TEST PLAN:
PASS - Build python3-k8sapp-openstack plugins
PASS - Build stx-openstack application
PASS - Upload/Apply/Remove stx-openstack
PASS - Live-migrate an instance
PASS - Manually reboot a compute node in which
an instance is running to ensure it is
correctly evacuated to another compute
Change-Id: Id7a93445af4115ee81b035b4f9dc7a6eb889555b
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
After upversioning openstack-helm and openstack-helm-infra, update
versions of helm charts introduced new docker images that are not used
by our stx-openstack distro but would still be downloaded during an
application apply if the helm values are not set to null.
This change removes unnecessary neutron-ovn and
libvirtd-export images.
Closes-Bug: 2043037
Test Plan:
PASS - Build stx-openstack-helm-fluxcd
PASS - Build stx-openstack application tarball
PASS - Upload/Apply/Remove stx-openstack application
Change-Id: I36bbde03785ad11b0cf97a9cf3e357ebd8084175
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
This change adds `python3-osc-placement` to the `stx-openstackclients`
container image so that the end user has access to CLIs provided by
Placement, e.g.:
$ openstack resource provider ...
As mentioned in LP-2042482, these CLIs can be used to compensate for
a change in the `openstack hypervisor` command that cause `vcpus_used`
and `free_disk_gb` fields to no longer be returned.
These are now only accessible via:
$ openstack resource provider inventory list
$ openstack resource provider usage show
Test Plan:
PASS - Build stx-debian base image
PASS - Build stx-openstackclients container image
PASS - Upload/apply stx-openstack
PASS - Upload built image to the system's registry and perform
helm-override to use it in the clients container
PASS - Verify that the CLIs are accessible:
$ openstack resource provider -h
PASS - Remove/delete stx-openstack
Depends-On: https://review.opendev.org/c/starlingx/tools/+/899898
Closes-Bug: 2042482
Change-Id: I1c72b135e7ff662b83de9eac1ec5c049943017f2
Signed-off-by: Luan Nunes Utimura <LuanNunes.Utimura@windriver.com>
The management network is used extensively for all internal
communication.
Since the original use of the network was a private network before
it was exposed for external communication in a distributed cloud
configuration, it was never designed to be reconfigured.
To support MGMT network reconfiguration the idea is to configure the
applications to use the hostname/FQDN instead of a static MGMT IP
address.
In this way the MGMT network can be changed and the services and
applications will still work since they are using the hostname/FQDN
and the DNS will be responsible to translate to the current MGMT
IP address.
The use of FQDN will be applied for all installation modes: AIO-SX,
AIO-DX, Standard, AIO-PLUS and DC subclouds. But given the
complexities of supporting the multi-host reconfiguration,
the MGMT network reconfiguration will focus on support for AIO-SX
only.
The DNSMASQ service must start as soon as possible to translate
the FQDN to IP address.
Test plan ( Debian only )
- AIO-SX and AIO-DX virtualbox installation IPv4/IPv6
- Standard virtualbox installation IPv6
- DC virtualbox installation IPv4 ( AIO-SX/DX subclouds )
- AIO-SX and AIO-DX installation IPv4/IPv6
- AIO-DX plus installation IPv6
- DC IPv6 and subcloud AIO-SX
- AIO-DX host-swact
- DC IPv4 virtualbox with subcloud AIO-DX and AIO-DX
- AIO-SX to AIO-DX migration
- netstat -tupl ( no services are using the MGMT IP address )
- Ran sanity/regression tests
- Openstack sanity/regression tests
Story: 2010722
Task: 48467
Depends-On: https://review.opendev.org/c/starlingx/config/+/886208
Change-Id: I8ce844977156f56edb861446640a0c3c6f4a8007
Signed-off-by: Fabiano Correa Mercer <fabiano.correamercer@windriver.com>
The security note OSSN-0090 [1] from Openstack describes a
configuration that makes it possible to open some known attack vectors
by which malicious data modification can occur.
The vulnerability only occurs if one of the following parameters are
set to True in Glance's configuration: `show_multiple_locations` or
`show_image_direct_url`. In the case of the STX-Openstack app, the
`show_image_direct_url` was being set to True in the app's plugin [2].
It looks like this configuration was just transported from when the
app's plugin was dettached from sysinv [3], which itself, was based on
an even older commit [4]. Unfortunately, the commit message of [4] has
no explanation on why this was required.
This commit changes the app's plugin to define both the
`show_image_direct_url` and the `show_multiple_locations` parameters to
`False`, since we can easily avoid the security issue described in [1]
by doing that, and it does not impact on the applications
functionalities, as seen in the test plan for this change.
[1] https://wiki.openstack.org/wiki/OSSN/OSSN-0090
[2] https://opendev.org/starlingx/openstack-armada-app/src/branch/master/python3-k8sapp-openstack/k8sapp_openstack/k8sapp_openstack/helm/glance.py#L155
[3] https://review.opendev.org/c/starlingx/openstack-armada-app/+/688190
[4] https://review.opendev.org/c/starlingx/config/+/611948
Test Plan:
PASS: Build python3-k8sapp-openstack and stx-openstack-helmf-fluxcd
packages
PASS: Build STX-Openstack helm charts
PASS: Upload / apply / remove STX-Openstack app
PASS: Inspection of /etc/glance/glance-api.conf shows that both the
show_multiple_locations and show_image_direct_url parameters are
set to `False`
Using OpenStack's CLI:
PASS: Image commands are executed as expected: `openstack image
list`, `openstack image show`
PASS: Create an image
PASS: Delete an image
PASS: Create a bootable volume from an image
PASS: Boot a VM using an image as the source
PASS: Boot a VM using the bootable volume as a source
PASS: Delete both VMs and the volume
Using Horizon dashboard:
PASS: All tenants are able to see and inspect images
PASS: Create an image
PASS: Delete an image
PASS: Create a bootable volume from an image
PASS: Boot a VM using an image as the source
PASS: Boot a VM using the bootable volume as a source
PASS: Delete both VMs and the volume
Closes-Bug: 1993606
Change-Id: I20f241224234353363c632085e3e41b91f97abf5
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
As a side-effect of the migration from the migration
from helm v2 to v3 and Armada to FluxCD, the helm
override of the horizon rbac policy was failing to
apply this file because it was too large. By splitting
this file and making two helm overrides the apply can
finish successfully.
Test plan:
PASS: system helm-override-update stx-openstack horizon openstack --reuse-values --values=rbac/horizon-policy-overrides.yml
system helm-override-update stx-openstack horizon openstack --reuse-values --values=rbac/horizon-nova-policy-overrides.yml
PASS: Reapply the app and check the helm overrides succeed
Closes bug: 2040165
Change-Id: Ib1c82544cd1f2335554f740bc3fe733ce57370ab
Signed-off-by: Romulo Leite <romulo.leite@windriver.com>
After STX-Openstack upversioned to Antelope, we noticed that it was not
possible to create VMs by volume, as they would be stuck on ERROR
status. The first proposed solution was to create a patch containing
[1] and [2], because, as specified in [3], Nova now requires
a service token in order to be able to manipulate Cinder volumes. This
unfortunately did not solve the issue by itself, as now an error message
showed up on the nova-conductor pods with the following (not full error
message, only important part): "nova.exception.RescheduledException:
Build of instance 2f32c7ea-1720-4f61-bce8-dbe970c40b0c was re-scheduled:
Secret not found: no secret with matching uuid 'a7f3ae2e-cee7-4f04-9402
-a78047747654". This UUID was not the same one present when issuing
`virsh secret-list` on Cinder, Nova and Libvirt containers.
Turns out openstack-helm and openstack-helm-infra have a Ceph UUID
hardcoded in them, in Cinder [4], Nova [5] [6] and Libvirt [7] values.
By changing these values to the UUID that libvirt was trying to find
(7f3ae2e-cee7-4f04-9402-a78047747654), and it worked to solve the issue.
However, it is not a good practice to use hardcoded values, and,
searching on where this UUID was coming from, it turns out it was
defined by the platform's Ceph configuration under
`/etc/ceph/ceph.conf`.
This still leaves the question, why was this working on Ussuri and
stopped working on Antelope? First of all, the Ceph official
documentation [8] [9] about using it with OpenStack explains the
process of adding the secret to libvirt, to store the ceph admin
keyring. You can see that the secret uuid is generated "on the fly" and
both docs mention that old/hard-coded value
(i.e., 457eb676-33da-42ec-9a8c-9293d545c337). This is the reason why it
used to work until our upversion to OpenStack Antelope/2023.1: this
UUID does not really matter (as long as nova and libvirt have the same
value for it)! It is a given UUID to the libvirt secret that will store
ceph keyring [10], and the key ring will ensure proper communication
between our services and the platform ceph.
What changed between Ussuri and Antelope (2023.1), is that now there is
a specific method [11] to set a default value (Ceph's Cluster UUID) for
this UUID when it is not specified in the driver configuration.
What this change does is dynamically read this `/etc/ceph/ceph.conf`
file to search for the UUID value, and use it to override the [4] [5]
[6] and [7] values. It also adds the patch including the Nova service
token configuration. The combination of these 2 changes allows VMs to be
created by volumes.
[1] 91c8a5baf2
[2] 7d39af25fd
[3] https://docs.openstack.org/releasenotes/cinder/2023.1.html#upgrade-notes
[4] https://opendev.org/openstack/openstack-helm/src/branch/master/cinder/values.yaml#L942
[5] https://opendev.org/openstack/openstack-helm/src/branch/master/nova/values.yaml#L594
[6] https://opendev.org/openstack/openstack-helm/src/branch/master/nova/values.yaml#L1432
[7] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/libvirt/values.yaml#L100
[8] https://github.com/ceph/ceph/blob/main/doc/rbd/rbd-openstack.rst
[9] https://docs.huihoo.com/ceph/v0.80.5/rbd/rbd-openstack/index.html
[10] https://opendev.org/starlingx/openstack-armada-app/src/branch/master/python3-k8sapp-openstack/k8sapp_openstack/k8sapp_openstack/helm/libvirt.py#L60
[11] 6464d37d16 (diff-9b122c182b4333b747e7fd7e07f73d68ff30256a)
Test Plan:
PASS: Build openstack-helm, python3-k8sapp-openstack and
stx-openstack-helm-fluxcd
PASS: Upload / apply / remove STX-Openstack
PASS: Create a VM by an image
PASS: Create a volume and launch a VM from it
PASS: Create a VM using the `boot-from-volume` flag
PASS: Delete a VM created by a volume
Closes-Bug: 2037463
Change-Id: Ia00bb8dbe3460ce817d69049f97f56a96ad6a298
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
In [1], two OpenStack clients were moved to the `DIST_PACKAGES` section
of the `stx-openstackclients` container image build recipe due to the
need to use packages patched exclusively for StarlingX:
* python3-cinderclient;
* python3-openstackclient.
Although this change served its purpose, it had a side-effect that
caused the main CLI, `openstack`, to stop recognizing other clients
installed via `PIP_PACKAGES`.
This occurred because once installed via `DIST_PACKAGES`, both
`cinderclient` and `openstackclient` started to reside in the
dist-packages/ directory, while all other clients continued to reside in
site-packages/. As `openstackclient` is the one responsible for the main
CLI, it stopped finding the other clients because its search directory
changed to dist-packages/.
Therefore, in this change, we chose to move all OpenStack clients to
DIST_PACKAGES. This way, it is guaranteed that the main CLI will
correctly identify the other OpenStack clients.
[1] https://review.opendev.org/c/starlingx/openstack-armada-app/+/896129
Test Plan:
PASS - Build stx-debian base image
PASS - Build stx-openstackclients container image
PASS - Upload/apply stx-openstack
PASS - Upload built image to the system's local registry and perform
a helm-override to use it in the OpenStack clients container
PASS - Run commands that had disappeared since the merge of [1], e.g.,
the ones provided by `heatclient`:
* openstack stack list
* openstack stack create
...
PASS - Remove/delete stx-openstack
Closes-Bug: 2039096
Co-authored-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
Co-authored-by: Romulo Leite <romulo.leite@windriver.com>
Change-Id: I61d653ceef07f99568a21b4ad6f6dceffed22ca1
Signed-off-by: Luan Nunes Utimura <LuanNunes.Utimura@windriver.com>
(cherry picked from commit 5bcbab406a)
After introducing a new set of layer-specific `sources.list` files in
[1], we can now update the `DIST_REPOS` of this image to additionally
use the `openstack` layer binary repository when searching for
dependencies of packages listed in `DIST_PACKAGES`.
This ensures that OpenStack Antelope packages will be built *without* OpenStack Victoria dependencies.
[1] https://review.opendev.org/c/starlingx/root/+/896277
Test Plan:
PASS - Build `stx-debian` base image
PASS - Build `stx-openstackclients` container image and confirm that
OpenStack Antelope dependencies were used in the build of
`python3-cinderclient` and `python3-openstackclient`
Depends-On: https://review.opendev.org/c/starlingx/root/+/897944
Closes-Bug: 2037339
Change-Id: If94d5281c5c2633b59a6aaf39f0881fb5cec61bb
Signed-off-by: Luan Nunes Utimura <LuanNunes.Utimura@windriver.com>
(cherry picked from commit 418a7bcb6e)
Ever since we migrated to containerized clients, it has been observed
that two clients -- `cinderclient` and `openstackclient` -- have lost an
additional parameter that was added by patches [1] and [2]:
`--location`.
Apparently, this is happening because the build of this container image
is prioritizing the download of indexed packages rather than the use of
the packages we deliver within the wheels tarball (which are patched
with modifications specific to StarlingX).
According to [3], when we specify an extra source of wheels for `pip`
with `--find-links` -- which is what `openstack/loci` does [4] -- it
does not mean that `pip` will necessarily prioritize this source over
others, such as PyPi.
Therefore, to ensure that our patched clients are used in the container
image, we moved them from `PIP_PACKAGES` to `DIST_PACKAGES` in this
change.
Note: The other clients can continue to be installed from indexed
packages. For this reason, they remain in `PIP_PACKAGES`.
[1] https://opendev.org/starlingx/openstack-armada-app/src/branch/master/upstream/openstack/python-cinderclient/debian/patches/0001-Add-location-parameter-for-volume-backup-creation.patch
[2] https://opendev.org/starlingx/openstack-armada-app/src/branch/master/upstream/openstack/python-openstackclient/debian/patches/0002-Add-location-parameter-for-volume-backup-creation.patch
[3] https://github.com/pypa/pip/issues/9959
[4] efccd0a853/scripts/pip_install.sh (L7)
Test Plan:
PASS - Build `stx-openstackclients` container image
PASS - Run image and confirm that both clients have the --location
parameter:
1. docker run -it <user>/stx-openstackclients:<tag> bash
2. openstack volume backup create -h
3. cinder help backup-create
Closes-Bug: 2036986
Co-Authored-By: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
Co-Authored-By: Romulo Leite <romulo.leite@windriver.com>
Change-Id: I4eeece7fc4a98b5254ca9367ca85c14ef5df7f3c
Signed-off-by: Luan Nunes Utimura <LuanNunes.Utimura@windriver.com>
(cherry picked from commit e25852370e)
The purpose of this change is to remove packages that are not used by
STX-Openstack from this repository. At the time these folders were
copied from the `starlingx/upstream` repo to here on [1], the goal was
to simply get the folder structure and all the packages, but, now that
the this repository is being actively used for the STX-Openstack
upversion to Antelope, we noticed that these packages are either not
used (barbican, keystone, openstack-resource-agents, horizon,
python-osc-lib, python-oslo.messaging, python-wsme, rabbitmq-server),
or were dropped from Openstack (gnocchi and the python-gnocchiclient
are not present on Antelope, as these services were removed from the
Openstack project [2] [3]).
Except for gnocchi and python-gnocchiclient, as explained above, these packages were present on the `starlingx/upstream` repository as they're required for the StarlingX builds and ISO, but not for the STX-Openstack application, for that reason, these are safe to be dropped from this repository.
[1] https://review.opendev.org/c/starlingx/openstack-armada-app/+/886027
[2] https://opendev.org/openstack/gnocchi
[3] https://opendev.org/openstack/python-gnocchiclient
Test Plan:
PASS: Removed packages are not found when issuing `build-pkgs`
PASS: Build all STX-Openstack images
PASS: Build STX-Openstack tarball
PASS: Upload / apply / remove STX-Openstack
Related-Bug: 2027589
Change-Id: I1697bce6b606fb603a0cb4a2c35b6255e129a080
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
This change updates the application plugins in order to ensure that all
libvirt/live-migration related traffic is happening through the
cluster-host-network. Currently most of the libvirt/live-migration
addresses are being solved through INADDR_ANY (0.0.0.0), and this route
resolution will vary between AIO, routes to oam-network, and Worker,
routes to mgmt-network. Both resolutions are not correct since the
correct network for such traffic should be the cluster-host-network.
Actually, current platform firewall will block any traffic through not
allowed oam-network ports.
The goal will be achieved by setting to the node's cluster-host IP:
* libvirt listen_addr
* nova.conf "live_migration_inbound_addr"
It is important to notice that in the current version of the
openstack-helm nova helm chart, there is a problem with
nova-compute-init.sh for this use case of ours, so an openstack-helm
patch was required to fix it.
Code that was previously implemented only for the Nova plugin and is now
required by the Libvirt plugin, was moved to the parent OpenStack class.
[1] 31be86079d
TEST PLAN:
PASS - Build stx-openstack application
PASS - Apply the application to an AIO-DX system
PASS - "$ sudo netstat -ltnp | grep <libvirtd pid>" to ensure that
libvirtd is listening on the correct cluster-host-net IP
PASS - Verify that the nova-compute.sh script was populated correctly
PASS - Test a VM live-migration on the controller+worker node
PASS - Verify that live_migration data in LibvirtLiveMigrateData has the
correct cluster-host-net IP address in its "target_connect_addr"
PASS - Apply the application to a Standard system
PASS - "$ sudo netstat -ltnp | grep <libvirtd pid>" to ensure that
libvirtd is listening on the correct cluster-host-net IP
PASS - Verify that the nova-compute.sh script was populated correctly
PASS - Test a VM live-migration on the worker node
PASS - Verify that live_migration data in LibvirtLiveMigrateData has the
correct cluster-host-net IP address in its "target_connect_addr"
Closes-Bug: 2037330
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
Change-Id: I37db601e4b1b0e397a1b8dbdad1a293ff25c2e55
After the introdution of [1], it was noted that Helm overrides were not
working properly for STX-Openstack. Althought they show up on
helm-override-show, they we're not being passed to Helm and Kubernetes.
This was caused because the [1] change updated the way that the
overrides are applied, requiring the `get_namespace` function on the
plugin to define where to apply these overrides, and, if this function
did not exist, it would default to the `default` namespace.
This change fixes that by adding the `get_namespace` function to the
OpenstackBaseHelm plugin, which is extended by the other STX-O plugins.
This change also does the following:
1) Updates the base class for ingress, memcached and garbd from
BaseHelm to OpenstackBaseHelm, as openstack.BaseHelm is the old base
class for the armada app and probably should be cleaned now that we
no longer support Armada.
2) Remove ingress customizations for the kube-system namespace, as
they're not used anymore and can be removed without any impact.
[1] https://review.opendev.org/c/starlingx/config/+/887430
Test Plan:
PASS: Build python3-k8sapp-openstack and stx-openstack-helm-fluxcd
PASS: Build STX-Openstack tarball
PASS: Upload / apply STX-Openstack on an AIO-SX machine with HTTPS
enabled
PASS: Verify that there's only one ingress pod per component
PASS: After passing helm overrides, verify that they're applied
(Example: change number of pods from 1 to 2)
PEND: Confirm overrides work for every Openstack component
Closes-Bug: 2036633
Change-Id: Id01a7367335213015531e1e9186b2b1cc677ef8e
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
When using container-backed OpenStack CLIs, it has been observed that
commands with multi-word options are failing to run due to poor parsing
of parameters by the wrapper script.
Currently, all commands that are redirected to the clients container are
expanded using the * parameter, i.e., $* [1]. However, according to [2],
a more appropriate option would be to expand the * parameter with the
Q operator, since:
> The expansion is a string that is the value of _parameter_ quoted in
a format that can be reused as input.
Which is exactly what we are doing with the wrapper script -- reusing
inputs but in a containerized environment.
[1] 4c238a8063/stx-openstack-helm-fluxcd/stx-openstack-helm-fluxcd/helm-charts/clients/templates/bin/_clients-wrapper.sh.tpl (L63-L64)
[2] https://www.gnu.org/software/bash/manual/html_node/Shell-Parameter-Expansion.html
Test Plan:
PASS - Build stx-openstack-helm-fluxcd package
PASS - Build stx-openstack helm charts
PASS - Upload/apply stx-openstack
PASS - Source `/var/opt/openstack/admin-openrc`
PASS - Run command with multi-word option(s), e.g.:
$ openstack project create \
--description="words separated by space" my_project
and confirm that it's executed successfully
PASS - Remove/delete stx-openstack
Closes-Bug: 2036447
Change-Id: I6441cf077e0bcfe386d7086ea90298e6dd247a2a
Signed-off-by: Luan Nunes Utimura <LuanNunes.Utimura@windriver.com>
There is no need of including stx-openstack-helm-fluxcd package to
StarlingX ISO, since this package is used only by the script that
generates the application tarball and this application is not delivered
along with the platform by default.
Having this package installed has no side-effects, but it installs
unnecessary files to /usr/lib on application, fluxcd and helm
directories.
TEST PLAN:
PASS - Successfully build a StarlingX ISO
Closes-Bug: 2028959
Signed-off-by: Thales Elero Cervi <thaleselero.cervi@windriver.com>
Change-Id: I342266c0932bb7853aa5a377b3a5663677858b27
It was observed that, when using the STX-Openstack app with HTTPS
enabled, it was not possible to visualize / edit / create images using
Horizon. This was caused because the SSL certificate (ca.crt) volume
mount path defined in Horizon's configuration [1] was not the same as
the default one created when using the Helm toolkit [2].
As specified in [3], one possible solution was to define a path to the
TLS secret to be created, but that caused other services in Horizon to
fail, so instead of doing that, the solution was to change Horizon's
configuration to search the ca.crt file in the correct path.
[1] https://opendev.org/openstack/openstack-helm/src/branch/master/horizon/values.yaml#L469
[2] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/helm-toolkit/templates/snippets/_tls_volume_mount.tpl#L56
[3] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/helm-toolkit/templates/snippets/_tls_volume_mount.tpl#L30
Test Plan:
PASS: Build openstack-helm and stx-openstack-helm-fluxcd
PASS: Build STX-Openstack tarball
PASS: Upload / apply STX-Openstack with HTTPS enabled
PASS: Create an image by using the Glance CLI
PASS: On Horizon, under Project -> Compute -> Images, verify that the
image is present
PASS: Create an image via Horizon
Closes-Bug: 2032980
Change-Id: If34c0d4a287804e4fce0e5f70bb97feb330be174
Signed-off-by: Lucas de Ataides <lucas.deataidesbarreto@windriver.com>
Lucas de Ataides