May 2023 - openstack-discuss - lists.openstack.org

[heat][magnum][tacker] Future of SoftwareDeployment support
by Takashi Kajinami 09 May '23

09 May '23

Hello, We discussed this briefly in the past thread where we discussed maintenance of os-*-agent repos, and also talked about this topic during Heat PTG, but I'd like to formalize the discussion to get a clear agreement. Heat has been supporting SoftwareDeployment resources to configure software in instances using some agents such as os-collect-config[1]. [1] https://docs.openstack.org/heat/latest/template_guide/software_deployment.h… This feature was initially developed to be used by TripleO (IIUC), but TripleO is retired now and we are losing the first motivation to maintain the feature. # Even TripleO replaced most of its usage of softwaredeployment by config-download lately. Because the heat project team has drunk dramatically recently, we'd like to put more focus on core features. For that aim we are now wondering if we can deprecate and remove this feature, and would like to hear from anyone who has any concerns about this. Quickly looking through the repos, it seems currently Magnum and Tacker are using SoftwareDeployment, and it'd be nice especially if we can understand their current requirements. 1. Magnum It seems SoftwareDeployment is used by k8s_fedora_atomic_v1 driver but I'm not too sure whether this driver is still supported, because Fedora Atomic was EOLed a while ago, right ? 2. Tacker SoftwareDeployment can be found in only test code in the tacker repo. We have some references kept in heat-translator which look related to TOSCA templates. Thank you, Takashi Kajinami

4 8

Unable to provision HCI node | Wallaby
by Swogat Pradhan 09 May '23

09 May '23

Hi, When i am running node provision command i am getting the following error: The full traceback is: File "/tmp/ansible_metalsmith_instances_payload_tmufs89r/ansible_metalsmith_instances_payload.zip/ansible/modules/metalsmith_instances.py", line 427, in main File "/tmp/ansible_metalsmith_instances_payload_tmufs89r/ansible_metalsmith_instances_payload.zip/ansible/modules/metalsmith_instances.py", line 340, in provision File "/usr/lib64/python3.6/concurrent/futures/thread.py", line 56, in run result = self.fn(*self.args, **self.kwargs) File "/tmp/ansible_metalsmith_instances_payload_tmufs89r/ansible_metalsmith_instances_payload.zip/ansible/modules/metalsmith_instances.py", line 372, in _provision_instance File "/usr/lib/python3.6/site-packages/metalsmith/_provisioner.py", line 488, in wait_for_provisioning raise exceptions.DeploymentFailed(str(exc)) "networks": [ { "network": "ctlplane", "vif": true }, { "network": "internal_api", "subnet": "internal_apis2_subnet" }, { "network": "tenant", "subnet": "tenants2_subnet" }, { "network": "storage", "subnet": "storages2_subnet" }, { "network": "storage_mgmt", "subnet": "storage_mgmts2_subnet" } ], "nics": [ { "network": "ctlplane" } ], "ssh_public_keys": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCb/KTQTouURPWFO0R1zGEIKXYUDQb4+pIgNuTJ7zA43jz9nyGt/pH1pnZAq71NmfL+sICFPf4uvhqFkMU7T0eC3TVuP87kZ8pAMh0D+NPqtRQJxK0WZO2h67dUKBAtW5WamxABhDh+XqmRPXE8Fl1VvzlKO/KZGUClk24BNGjt/nqho9FGskNY/vZLQV/gZzrKfHUYpcDxIg6NpnNE6bGdy4tyL4JwYcdTP8ovU1JhKMXSTjk8WrGz/OQB8a4Pgq0WWgIRWvwZDuUwFWiK6aV7gkjhMXwwtZ7jq9fQOs/hcleATX7Cq77ayJW8DusxQLynbMrh/dBs3Smgp1Ncd3rthpJz2ujBg7ymScCq4ya0W1RkbzZ6H8kVT0hppO93Ip8VFTMnPDoWONQFdAbAVhaamycVMxxbGatHVYGGXIMMBEL1MO4ncIW4f46vNffIhmoTvG20ncy2zba7hk9D4NMbqEpyR3NG1BnMHW0h9bYp2K9+jOWS9MUfakD8kNi8Ff0= stack(a)hkg2director.bdxworld.com ", 2023-05-09 22:18:08.565576 | 48d539a1-1679-0477-63a8-000000000018 | FATAL | Provision instances | localhost | error={ "changed": false, "invocation": { "module_args": { "api_timeout": null, "auth": null, "auth_type": null, "availability_zone": null, "ca_cert": null, "clean_up": false, "client_cert": null, "client_key": null, "concurrency": 1, "instances": [ { "config_drive": { "meta_data": { "instance-type": "DistributedComputeHCI" } }, "hostname": "dcn01-hci-2", "image": { "href": "file:///var/lib/ironic/images/overcloud-full.raw", "kernel": "file:///var/lib/ironic/images/overcloud-full.vmlinuz", "ramdisk": "file:///var/lib/ironic/images/overcloud-full.initrd" }, "name": "17107583-48da-43eb-9e38-63e250848d05", "network_config": { "template": "/home/stack/dcn01/hci_network_bond.j2" }, "networks": [ { "network": "ctlplane", "vif": true }, { "network": "internal_api", "subnet": "internal_apis2_subnet" }, { "network": "tenant", "subnet": "tenants2_subnet" }, { "network": "storage", "subnet": "storages2_subnet" }, { "network": "storage_mgmt", "subnet": "storage_mgmts2_subnet" } ], "nics": [ { "network": "ctlplane" } ], "ssh_public_keys": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCb/KTQTouURPWFO0R1zGEIKXYUDQb4+pIgNuTJ7zA43jz9nyGt/pH1pnZAq71NmfL+sICFPf4uvhqFkMU7T0eC3TVuP87kZ8pAMh0D+NPqtRQJxK0WZO2h67dUKBAtW5WamxABhDh+XqmRPXE8Fl1VvzlKO/KZGUClk24BNGjt/nqho9FGskNY/vZLQV/gZzrKfHUYpcDxIg6NpnNE6bGdy4tyL4JwYcdTP8ovU1JhKMXSTjk8WrGz/OQB8a4Pgq0WWgIRWvwZDuUwFWiK6aV7gkjhMXwwtZ7jq9fQOs/hcleATX7Cq77ayJW8DusxQLynbMrh/dBs3Smgp1Ncd3rthpJz2ujBg7ymScCq4ya0W1RkbzZ6H8kVT0hppO93Ip8VFTMnPDoWONQFdAbAVhaamycVMxxbGatHVYGGXIMMBEL1MO4ncIW4f46vNffIhmoTvG20ncy2zba7hk9D4NMbqEpyR3NG1BnMHW0h9bYp2K9+jOWS9MUfakD8kNi8Ff0= stack(a)hkg2director.bdxworld.com ", "user_name": "heat-admin" } ], "interface": "public", "log_level": "info", "region_name": null, "state": "present", "timeout": 3600, "validate_certs": null, "wait": true } }, "logging": "Created port dcn01-hci-2-ctlplane (UUID ce763b38-b047-40bc-be44-9c9da8bd2e30) for node singapore-HCI3 (UUID 17107583-48da-43eb-9e38-63e250848d05) with {'network_id': '1fad76a3-aa2a-4213-8c37-eb89629da523', 'name': 'dcn01-hci-2-ctlplane'}\nAttached port dcn01-hci-2-ctlplane (UUID ce763b38-b047-40bc-be44-9c9da8bd2e30) to node singapore-HCI3 (UUID 17107583-48da-43eb-9e38-63e250848d05)\nProvisioning started on node singapore-HCI3 (UUID 17107583-48da-43eb-9e38-63e250848d05)\n", "msg": "Node 17107583-48da-43eb-9e38-63e250848d05 reached failure state \"deploy failed\"; the last error is Deploy step deploy.prepare_instance_boot failed: Failed to install a bootloader when deploying node 17107583-48da-43eb-9e38-63e250848d05. Error: Installing GRUB2 boot loader to device /dev/sda failed with Unexpected error while running command.\nCommand: chroot /tmp/tmp8_wa6g6q /bin/sh -c \"grub2-install /dev/sda\"\nExit code: 1\nStdout: ''\nStderr: 'grub2-install: error: this utility cannot be used for EFI platforms because it does not support UEFI Secure Boot.\\n'." I have already provisioned 2 other nodes using the same hardware, but the node provisioning is failing in this particular node. With regards, Swogat Pradhan

2 1

[neutron] When num of port mappings is substantial, the response time of List API so slow
by 韩光宇 09 May '23

09 May '23

Hello， I have a Victoria cluster with 1 controller node(also have nova-compute service) and two compute node. ALL node boasts 128 CPU cores and 512GB of memory. I established 1500 port mappings for a single floating IP A. At this point, the response time for the "List Floating IP Port Forwardings" API[1] becomes remarkably slow, approaching a duration of 9 minutes. Does anyone comprehend the cause of this phenomenon or how should I investigate it? I am immensely grateful for any assistance provided. Best regards, Han Guangyu [1] https://docs.openstack.org/api-ref/network/v2/index.html#list-floating-ip-p…

2 2

[Octavia] importlib fails to read first 5 chars from file
by Mihai Gheorghe 09 May '23

09 May '23

Hello, We are experiencing a strange problem with Octavia API in an Openstack deployment. A bit of context: we have an Openstack Ussuri deployment (HA) on Ubuntu Focal. Most Openstack services are running on LXD containers on 3 baremetals. There are also two OVN-dedicated-chassis which act as gateways and nova-compute nodes. A couple of days ago we updated all the packages in the environment to the latest versions (baremetals and lxc containers). After the updates, we started seeing problems with the Octavia API. The API would randomly give an internal server error. Octavia API is running under Apache2 WSGI on 3 LXD containers on 3 separate nodes. Looking into one of the Octavia container under /var/log/apache2/octavia_error.log, we found the following error: [Fri Apr 28 10:11:07.509268 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] mod_wsgi (pid=1312420): Failed to exec Python script file '/usr/bin/octavia-wsgi'. [Fri Apr 28 10:11:07.509455 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] mod_wsgi (pid=1312420): Exception occurred processing WSGI script '/usr/bin/octavia-wsgi'. [Fri Apr 28 10:11:07.511688 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] Traceback (most recent call last): [Fri Apr 28 10:11:07.511884 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "/usr/bin/octavia-wsgi", line 52, in <module> [Fri Apr 28 10:11:07.512260 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] application = setup_app() [Fri Apr 28 10:11:07.512343 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "/usr/lib/python3/dist-packages/octavia/api/app.py", line 59, in setup_app [Fri Apr 28 10:11:07.512435 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] pecan_config = get_pecan_config() [Fri Apr 28 10:11:07.512513 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "/usr/lib/python3/dist-packages/octavia/api/app.py", line 40, in get_pecan_config [Fri Apr 28 10:11:07.512529 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] return pecan_configuration.conf_from_file(filename) [Fri Apr 28 10:11:07.512543 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "/usr/lib/python3/dist-packages/pecan/configuration.py", line 176, in conf_from_file [Fri Apr 28 10:11:07.512553 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] SourceFileLoader(module_name, abspath).load_module(module_name) [Fri Apr 28 10:11:07.512567 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap_external>", line 522, in _check_name_wrapper [Fri Apr 28 10:11:07.512705 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap_external>", line 1027, in load_module [Fri Apr 28 10:11:07.512725 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap_external>", line 852, in load_module [Fri Apr 28 10:11:07.512737 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap>", line 265, in _load_module_shim [Fri Apr 28 10:11:07.512750 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap>", line 702, in _load [Fri Apr 28 10:11:07.512763 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap>", line 671, in _load_unlocked [Fri Apr 28 10:11:07.512775 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap_external>", line 844, in exec_module [Fri Apr 28 10:11:07.512788 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap_external>", line 981, in get_code [Fri Apr 28 10:11:07.512800 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap_external>", line 911, in source_to_code [Fri Apr 28 10:11:07.512839 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed [Fri Apr 28 10:11:07.512869 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] File "/usr/lib/python3/dist-packages/octavia/api/config.py", line 1 [Fri Apr 28 10:11:07.512893 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] Copyright 2014 Rackspace [Fri Apr 28 10:11:07.512921 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] ^ [Fri Apr 28 10:11:07.512938 2023] [wsgi:error] [pid 1312420:tid 140012169602816] [remote 127.0.0.1:59914] IndentationError: unexpected indent The original /usr/lib/python3/dist-packages/octavia/api/config.py file is added to the bug report. As seen in the file, the first line starts with a comment, but python is trying to run it as code. Removing the first 5 charactersin the file so that string above starts right after the comment yelds the following traceback: [Wed Apr 26 17:08:22.609980 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] mod_wsgi (pid=330647): Failed to exec Python script file '/usr/bin/octavia-wsgi'. [Wed Apr 26 17:08:22.610114 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] mod_wsgi (pid=330647): Exception occurred processing WSGI script '/usr/bin/octavia-wsgi'. [Wed Apr 26 17:08:22.611039 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] Traceback (most recent call last): [Wed Apr 26 17:08:22.611097 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] File "/usr/bin/octavia-wsgi", line 52, in <module> [Wed Apr 26 17:08:22.611106 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] application = setup_app() [Wed Apr 26 17:08:22.611125 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] File "/usr/lib/python3/dist-packages/octavia/api/app.py", line 59, in setup_app [Wed Apr 26 17:08:22.611135 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] pecan_config = get_pecan_config() [Wed Apr 26 17:08:22.611152 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] File "/usr/lib/python3/dist-packages/octavia/api/app.py", line 40, in get_pecan_config [Wed Apr 26 17:08:22.611160 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] return pecan_configuration.conf_from_file(filename) [Wed Apr 26 17:08:22.611178 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] File "/usr/lib/python3/dist-packages/pecan/configuration.py", line 168, in conf_from_file [Wed Apr 26 17:08:22.611327 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] compiled = compile(f.read(), abspath, 'exec') [Wed Apr 26 17:08:22.611355 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] File "/usr/lib/python3/dist-packages/octavia/api/config.py", line 1 [Wed Apr 26 17:08:22.611381 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] right 2014 Rackspace [Wed Apr 26 17:08:22.611419 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] ^ [Wed Apr 26 17:08:22.611437 2023] [wsgi:error] [pid 330647:tid 140629468657408] [remote 127.0.0.1:55142] SyntaxError: invalid syntax It seems that when the source file is read by python, the first 5 characters are skipped for some reason. Digging deeper, I see no reason for importlib to trim those characters. Internally it uses _io.open_code().read() which should return the entire file without trimming anything If adding the comment after the 5th char on the first line, the file is read as is should but the error moves to a different file: [Fri Apr 28 10:20:24.730194 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] mod_wsgi (pid=1316806): Failed to exec Python script file '/usr/bin/octavia-wsgi'. [Fri Apr 28 10:20:24.730379 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] mod_wsgi (pid=1316806): Exception occurred processing WSGI script '/usr/bin/octavia-wsgi'. [Fri Apr 28 10:20:24.732137 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] Traceback (most recent call last): [Fri Apr 28 10:20:24.732294 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/bin/octavia-wsgi", line 52, in <module> [Fri Apr 28 10:20:24.732316 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] application = setup_app() [Fri Apr 28 10:20:24.732340 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/lib/python3/dist-packages/octavia/api/app.py", line 62, in setup_app [Fri Apr 28 10:20:24.732353 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] return pecan_make_app( [Fri Apr 28 10:20:24.732381 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/lib/python3/dist-packages/pecan/__init__.py", line 86, in make_app [Fri Apr 28 10:20:24.732400 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] app = Pecan(root, **kw) [Fri Apr 28 10:20:24.732453 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/lib/python3/dist-packages/pecan/core.py", line 832, in __init__ [Fri Apr 28 10:20:24.732475 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] super(Pecan, self).__init__(*args, **kw) [Fri Apr 28 10:20:24.732516 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/lib/python3/dist-packages/pecan/core.py", line 240, in __init__ [Fri Apr 28 10:20:24.732536 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] root = self.__translate_root__(root) [Fri Apr 28 10:20:24.732582 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/lib/python3/dist-packages/pecan/core.py", line 275, in __translate_root__ [Fri Apr 28 10:20:24.732618 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] module = __import__(name, fromlist=fromlist) [Fri Apr 28 10:20:24.732645 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/lib/python3/dist-packages/octavia/api/root_controller.py", line 24, in <module> [Fri Apr 28 10:20:24.732716 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] from octavia.api.v2 import controllers as v2_controller [Fri Apr 28 10:20:24.732760 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/lib/python3/dist-packages/octavia/api/v2/controllers/__init__.py", line 19, in <module> [Fri Apr 28 10:20:24.732821 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] from octavia.api.v2.controllers import availability_zone_profiles [Fri Apr 28 10:20:24.732908 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] File "/usr/lib/python3/dist-packages/octavia/api/v2/controllers/availability_zone_profiles.py", line 1 [Fri Apr 28 10:20:24.732952 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] Copyright 2019 Verizon Media [Fri Apr 28 10:20:24.733024 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] ^ [Fri Apr 28 10:20:24.733107 2023] [wsgi:error] [pid 1316806:tid 140384699016960] [remote 127.0.0.1:41802] SyntaxError: invalid syntax As far as we can tell, this problem appears when importlib reads the file and hands it over incomplete (missing the first 5 chars). This issue only occurs on the Octavia containers and not on the other Openstack services. The other thing is that the fault is not consistent. It happens at Apache2 reload or restart but not everytime. Once in a few restarts. When the problem occurs, Octavia API is down. Env details: OS: Ubuntu 20.04 Kernel: 5.4.0-147-generic Openstack: Ussuri Octavia: ii octavia-api 6.2.2-0ubuntu1 all OpenStack Load Balancer as a Service - API frontend ii octavia-common 6.2.2-0ubuntu1 all OpenStack Load Balancer as a Service - Common files ii octavia-driver-agent 6.2.2-0ubuntu1 all OpenStack Load Balancer Service - Driver Agent ii octavia-health-manager 6.2.2-0ubuntu1 all OpenStack Load Balancer Service - Health manager ii octavia-housekeeping 6.2.2-0ubuntu1 all OpenStack Load Balancer Service - Housekeeping manager ii octavia-worker 6.2.2-0ubuntu1 all OpenStack Load Balancer Service - Worker ii python3-octavia 6.2.2-0ubuntu1 all OpenStack Load Balancer as a Service - Python libraries ii python3-octavia-lib 2.0.0-0ubuntu1 all Library to support Octavia provider drivers ii python3-ovn-octavia-provider 0.1.0-0ubuntu1 all OpenStack Octavia Integration with OVN - Python 3 library Python: Python 3.8.10 LXD: lxd 5.13-cea5ee2 24758 latest/stable canonical✓ - A bug was filled on launchpad for this issue: https://bugs.launchpad.net/ubuntu/+source/importlib/+bug/2018011 Thanks! Bug #2018011 “python3 - importlib fails to read first 5 chars fr...” : Bugs : importlib package : Ubuntu<https://bugs.launchpad.net/ubuntu/+source/importlib/+bug/2018011> A bit of context: we have an Openstack Ussuri deployment (HA) on Ubuntu Focal. Most Openstack services are running on LXD containers on 3 baremetals. There are also two OVN-dedicated-chassis which act as gateways and nova-compute nodes. A couple of days ago we updated all the packages in the environment to the latest versions (baremetals and lxc containers). After the updates, we started seeing problems with the Octavia API. The API would randomly give an internal server error. Octavia API is... bugs.launchpad.net

1 0

[kolla-ansible][xena][vmware][neutron]
by Andrej Moravčík 09 May '23

09 May '23

Hello community, I am evaluating OpenStack release Xena with VMware vSphere deployed using Kolla-ansible. I would really appreciate if someone with similar environment can confirm my findings or share his/her experience. I did some research and choose Xena, because it is still maintained release and vmware-nsx latest stable branch is xena. I have built customised Docker images with additional Neutron plugins from opendev.org/x/vmware-nsx<http://opendev.org/x/vmware-nsx>, then I deployed single controller using all-in-one Ansible inventory with customised globals.yml according https://docs.openstack.org/kolla-ansible/xena/reference/compute/vmware-guid… 1) Neutron creates flat or VLAN type provider networks and add related Distributed Virtual Port Group (PG) to vSphere Distributed Switch (vDS or DVS). PG is automatically created with naming convention “<network name>”-“<network ID suffix>", which may not be suitable for same use cases, eg. PG was created by Cisco ACI ahead of Neutron and is part of ACI EPG. Question: is this PG naming convention fixed by design or is it configurable? If I want to use existing vDS PG with Neutron how this can be achieved? 2) Neutron metadata and DHCP agents are not accessible to Nova instance attached to DVS PG. I can deploy simple instance from Cirros image, but I cannot provision DHCP or fixed IP address. Provisioning via config drive doesn’t work either, I filled bug report to Nova … https://bugs.launchpad.net/nova/+bug/2018973 The documentation says … "For VMware DVS, the Neutron DHCP agent does not attaches to Open vSwitch inside VMware environment, but attach to the Open vSwitch bridge called br-dvs on the OpenStack side and replies to/receives DHCP packets through VLAN. Similar to what the DHCP agent does, Neutron metadata agent attaches to br-dvs bridge and works through VLAN.” Question: Is it expected that Kolla-ansible creates working configurations for Nova and Neutron, if all related options in globals.yml are set up? Or further adjustment is needed on Openstack or vCenter side? Thank you. — Andrej Moravcik ________________________________ Táto správa a jej prílohy sú dôverné. Prosím, narábajte s týmito informáciami ako s dôvernými a nezverejňujte, nekopírujte ani neposielajte tieto informácie bez predchádzajúceho súhlasu spoločnosti Aliter Technologies, a.s. Ak nie ste adresátom indikovaným v záhlaví tejto správy alebo želaný príjemca, upovedomte prosím spoločnosť Aliter Technologies, a.s. odpoveďou na tento e-mail a pôvodnú správu vymažte zo svojho systému. Aliter Technologies - registrovaná ochranná známka pre EU, USA This message and any attachments are confidential. Please treat the information as confidential, and do not disclose, copy or deliver this message to anyone without Aliter Technologies' approval. If you are not the addressee indicated in this message or an intended recipient please notify Aliter Technologies a.s. by return e-mail and delete the message from your system. Aliter Technologies - Registered in WIPO & U.S. Patent and Trademark Office

1 0

[neutron][Secure RBAC] New policies enabled by default
by Slawek Kaplonski 09 May '23

09 May '23

Hi, It's just a heads up that [1] was merged recently and Neutron is using new, secure RBAC policies by default now. If You would see any issues with that, please report bug(s) and let me know. [1] https://review.opendev.org/c/openstack/neutron/+/879827 -- Slawek Kaplonski Principal Software Engineer Red Hat

3 4

[neutron] Bug deputy May 01 - May 07
by Rodolfo Alonso Hernandez 09 May '23

09 May '23

Hello Neutrinos: This is the bug report from last week. High: * https://bugs.launchpad.net/neutron/+bug/2018727: [SRBAC] API policies for get_policy_*_rule are wrong. Assigned to Slawek. Medium: * https://bugs.launchpad.net/neutron/+bug/2018009: ML2 context not considering tags at network creation and update. Assigned to Miro. * https://bugs.launchpad.net/neutron/+bug/2018289: OVN trunk subport missing bounding information. Assigned to Arnau. * https://bugs.launchpad.net/neutron/+bug/2018529: [OVN] Virtual ports cannot be used as VM ports. Assigned to Rodolfo. * https://bugs.launchpad.net/neutron/+bug/2018585: [SRBAC]New policies change the behavior for check rule type. Assigned to Rodolfo. * https://bugs.launchpad.net/neutron/+bug/2018599: Disable config option use_random_fully does not work. *Not assigned*. * https://bugs.launchpad.net/neutron/+bug/2018737: neutron-dynamic-routing announces routes for disabled routers. Assigned to Felix. Low: * https://bugs.launchpad.net/neutron/+bug/2018474: Unnecessary agent resource version. *Not assigned*. Regards.

1 0

Stepping down as Ironic core
by Arne Wiebalck 09 May '23

09 May '23

Dear all, With a change in my role at work about a year ago, the time I have had available for upstream technical work has dropped significantly. I would therefore like to step down from my role as one of the Ironic cores. I am really grateful to have worked closely with this team of incredibly talented, helpful and kind people, and would like to use this occasion to thank them for all the support they have provided during these past years ... and of course for all the fun we had! Cheers, Arne -- Arne Wiebalck CERN IT

4 3

Using Veeam
by Robert Winbladh 09 May '23

09 May '23

Hi, Not sure I am in the right place but thought I would give it a go. We have a s3 service using IBM Spectrum Scale that builds on/uses Openstack Swift. The problem that we are having is that if the client/user is using Veeam the bucket gets locked. IBM explains that it has something to do with outstanding requests/timeouts. And the bucket gets locked, and the client/user/Veeam cannot access it any longer. This happens all the time. So my questions is: * What can I do about it? Anything that can be tuned in Swift? * IBM tells me to spread the load across multiple buckets - but Veeam does not have support for that (as far as I understand) * Any kind of tuning that needs to be done in Veeam (if anyone would know) * We have tried lowering "concurrent tasks" to 1, but still the bucket gets locked. [cid:image001.png@01D98259.E2C0B2C0] Robert Winbladh Seniorkonsult Technical Operations Manager Incident Manager Problem Manager Change Control Board member Asigra Certified Engineer IBM Spectrum Protect

1 0

[gate][tripleo] gate blocker
by Ananya Banerjee 09 May '23

09 May '23

Hello, All Centos 8 jobs which deploy standalone are failing at the moment. Please hold rechecks if you hit standalone deploy failure on Centos 8 jobs. We are working on the bug: https://bugs.launchpad.net/tripleo/+bug/2018588 Thanks, Ananya -- Ananya Banerjee, RHCSA, RHCE-OSP Software Engineer Red Hat EMEA <https://www.redhat.com/> anbanerj(a)redhat.com M: +491784949931 IM: frenzy_friday @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com/>

1 1