July 2022 - openstack-discuss - lists.openstack.org

A centralized list of usable vs unusable projects?
by Vince Mulhollon 04 Jul '22

04 Jul '22

Hi, Can anyone point me to a status board or other format identifying which projects are uninstallable or unusable perhaps organized by release? Specifically for Yoga on Kolla-Ansible although "in general" would also be useful. I have a test cluster, and I'm exercising Yoga using Ubuntu hosts and Kolla-Ansible, and the online docs imply every project is up and installable and usable. However, from my notes so far: "everyone knows" Freezer hasn't been installable for many years and requires an ElasticSearch version from last decade (Every project that uses ElasticSearch needs a different and incompatible version of ES, honestly just in general, that's not just an OpenStack phenomena), Murano has been uninstallable for years AND hard crashes all of Horizon if you try to install it, Monasca has been uninstallable for around a year, as near as I can tell, due to a crash loop in the log persister, every Watcher container crash loops for no apparent reason after every Kolla-Ansible installation, although I recently hand installed Watcher on a separate Yoga cluster and it "worked" or at least didn't crash loop, I will research this in more detail and add/update issues and storyboards. The docs claim Magnum works great with Docker Swarm and I have a specific enduser application for Swarm so I set up Magnum successfully, then learned "everyone knows" that Magnum doesn't actually work for Docker Swarm, so I was very annoyed at that. I haven't even tried Ceilometer-and-related on Yoga, although if Monasca is dead maybe I should add it to the testing plan. The vast majority of projects do "just work" which is super awesome of course. My point is, I can't find a status board type of page, or any sort of centralized list, it seems like it would be incredibly useful, so I'm making my own list of what works, and what does not work, for my own use, and I'd feel silly if there's already some service or page or dashboard implementing this effort that I couldn't find. I'd certainly contribute data toward such a status page, as I'm running tests on my test cluster anyway, may as well share the results. Thanks!

2 1

[nova][placement] Spec review day tomorrow
by Sylvain Bauza 04 Jul '22

04 Jul '22

Hey members, Just a reminder we'll have a nova/placement spec review day happening on tomorrow July 5th. Sharpen your pens and prepare your specs for review, it would be greatly appreciated. -Sylvain

1 0

[glance][ops] [nova] Disabling an image
by Massimo Sgaravatto 04 Jul '22

04 Jul '22

Dear all What is the blessed method to avoid using an image for new virtual machines without causing problems for existing instances using that image ? If I deactivate the image, I then have problems resizing instances using that image [*]: it claims that image download is forbidden since the image was deactivated Thanks, Massimo [*] | fault | {'code': 500, 'created': '2022-06-30T07:57:30Z', 'message': 'Not authorized for image dd1492d5-17a2-4dc2-a4e3-ec6c99255e4b.', 'details': 'Traceback (most recent call last):\n File "/usr/lib/python3.6/site-packages/nova/image/glance.py", line 377, in download\n context, 2, \'data\', args=(image_id,))\n File "/usr/lib/python3.6/site-packages/nova/image/glance.py", line 191, in call\n result = getattr(controller, method)(*args, **kwargs)\n File "/usr/lib/python3.6/site-packages/glanceclient/common/utils.py", line 670, in inner\n return RequestIdProxy(wrapped(*args, **kwargs))\n File "/usr/lib/python3.6/site-packages/glanceclient/v2/images.py", line 255, in data\n resp, body = self.http_client.get(url)\n File "/usr/lib/python3.6/site-packages/keystoneauth1/adapter.py", line 395, in get\n return self.request(url, \'GET\', **kwargs)\n File "/usr/lib/python3.6/site-packages/glanceclient/common/http.py", line 380, in request\n return self._handle_response(resp)\n File "/usr/lib/python3.6/site-packages/glanceclient/common/http.py", line 120, in _handle_response\n raise exc.from_response(resp, resp.content)\nglanceclient.exc.HTTPForbidden: HTTP 403 Forbidden: The requested image has been deactivated. Image data download is forbidden.\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 201, in decorated_function\n return function(self, context, *args, **kwargs)\n File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 5950, in finish_resize\n context, instance, migration)\n File "/usr/lib/python3.6/site-packages/oslo_utils/excutils.py", line 227, in __exit__\n self.force_reraise()\n File "/usr/lib/python3.6/site-packages/oslo_utils/excutils.py", line 200, in force_reraise\n raise self.value\n File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 5932, in finish_resize\n migration, request_spec)\n File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 5966, in _finish_resize_helper\n request_spec)\n File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 5902, in _finish_resize\n self._set_instance_info(instance, old_flavor)\n File "/usr/lib/python3.6/site-packages/oslo_utils/excutils.py", line 227, in __exit__\n self.force_reraise()\n File "/usr/lib/python3.6/site-packages/oslo_utils/excutils.py", line 200, in force_reraise\n raise self.value\n File "/usr/lib/python3.6/site-packages/nova/compute/manager.py", line 5890, in _finish_resize\n block_device_info, power_on)\n File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 11343, in finish_migration\n fallback_from_host=migration.source_compute)\n File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 4703, in _create_image\n injection_info, fallback_from_host)\n File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 4831, in _create_and_inject_local_root\n instance, size, fallback_from_host)\n File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 10625, in _try_fetch_image_cache\n trusted_certs=instance.trusted_certs)\n File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/imagebackend.py", line 275, in cache\n *args, **kwargs)\n File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/imagebackend.py", line 638, in create_image\n prepare_template(target=base, *args, **kwargs)\n File "/usr/lib/python3.6/site-packages/oslo_concurrency/lockutils.py", line 391, in inner\n return f(*args, **kwargs)\n File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/imagebackend.py", line 271, in fetch_func_sync\n fetch_func(target=target, *args, **kwargs)\n File "/usr/lib/python3.6/site-packages/nova/virt/libvirt/utils.py", line 395, in fetch_image\n images.fetch_to_raw(context, image_id, target, trusted_certs)\n File "/usr/lib/python3.6/site-packages/nova/virt/images.py", line 115, in fetch_to_raw\n fetch(context, image_href, path_tmp, trusted_certs)\n File "/usr/lib/python3.6/site-packages/nova/virt/images.py", line 106, in fetch\n trusted_certs=trusted_certs)\n File "/usr/lib/python3.6/site-packages/nova/image/glance.py", line 1300, in download\n trusted_certs=trusted_certs)\n File "/usr/lib/python3.6/site-packages/nova/image/glance.py", line 379, in download\n _reraise_translated_image_exception(image_id)\n File "/usr/lib/python3.6/site-packages/nova/image/glance.py", line 1031, in _reraise_translated_image_exception\n raise new_exc.with_traceback(exc_trace)\n File "/usr/lib/python3.6/site-packages/nova/image/glance.py", line 377, in download\n context, 2, \'data\', args=(image_id,))\n File "/usr/lib/python3.6/site-packages/nova/image/glance.py", line 191, in call\n result = getattr(controller, method)(*args, **kwargs)\n File "/usr/lib/python3.6/site-packages/glanceclient/common/utils.py", line 670, in inner\n return RequestIdProxy(wrapped(*args, **kwargs))\n File "/usr/lib/python3.6/site-packages/glanceclient/v2/images.py", line 255, in data\n resp, body = self.http_client.get(url)\n File "/usr/lib/python3.6/site-packages/keystoneauth1/adapter.py", line 395, in get\n return self.request(url, \'GET\', **kwargs)\n File "/usr/lib/python3.6/site-packages/glanceclient/common/http.py", line 380, in request\n return self._handle_response(resp)\n File "/usr/lib/python3.6/site-packages/glanceclient/common/http.py", line 120, in _handle_response\n raise exc.from_response(resp, resp.content)\nnova.exception.ImageNotAuthorized: Not authorized for image dd1492d5-17a2-4dc2-a4e3-ec6c99255e4b.\n'} |

3 5

[neutron] Bug deputy Jun 27 to Jul 3
by Rodolfo Alonso Hernandez 04 Jul '22

04 Jul '22

1 0

Problem while launching an instance directly from an image "Volume did not finish being created even after we waited 203 seconds or 61 attempts"
by A Monster 03 Jul '22

03 Jul '22

I've deployed openstack using kolla, when I try to launch an instance directly from any image, after some time waiting for Block Device Mapping I get the following error : Build of instance 4cf01ba2-05b3-44e9-a685-8875d8c96b4e aborted: Volume > 01739e82-9e66-41f7-be74-dfbbdcd6746e did not finish being created even > after we waited 203 seconds or 61 attempts. And its status is creating. I've tried increasing *block_device_allocate_retries=400 *and *block_device_allocate_retries_interval=3 *, however I keep getting the same error. But when I create a volume from an image, then launch an instance from that same volume, it works just fine. Any suggestions for this issue?

2 1

[kolla-ansible][centos][yoga] Problems VpnaaS and containers
by Franck VEDEL 01 Jul '22

01 Jul '22

Hello I hope to have some help on a point that was bothering me last year, and which still does not work. I was a year ago on Wallaby, after 2 updates, I'm currently on Yoga. I use kolla-ansible, and openstack-kolla/centos-source images. Last year, I found the following ebug: https://bugs.launchpad.net/neutron/+bug/1938571 I tried with the Yoga update: exactly the same problem "Command: ['ipsec', 'whack', '--status'] Exit code: 33 Stdout: Stderr: whack: Pluto is not running (no "/run/pluto/pluto.ctl") ; Stderr: » Should I conclude that this bug will never be fixed and that it is impossible to have vpnaas functionality with centos images? Second question: let's imagine that I change the line kolla_base_distro: "centos" in kolla_base_distro: "ubuntu" Does this have a chance of working? I can't see all the possible problems. Thanks for your help. Franck

1 0

[all][tc] What's happening in Technical Committee: summary 01 July 2022: Reading: 5 min
by Ghanshyam Mann 01 Jul '22

01 Jul '22

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on 30 June. Most of the meeting discussions are summarized in this email. Meeting full logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-06-30-15.00.log.html * Next TC weekly meeting will be on 7 July Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by 6 July. 2. What we completed this week: ========================= * Retired openstack-helm-deployments[2]. * Added Cinder Dell EMC PowerStore charm[3] 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[4], Two are completed and others items are in-progress. Open Reviews ----------------- * Three open reviews for ongoing activities[5]. Create the Environmental Sustainability SIG --------------------------------------------------- We discussed it in TC meeting but did not conclude anything as Kendal would like to wait for more feedback in review[6]. New ELK service dashboard: e-r service ----------------------------------------------- There are good progress on brining elastic-recheck back. From no onwards, we can track the progress in TacT SIG. Feel free to ping dpawlik on #openstack-infra for any query or help. Consistent and Secure Default RBAC ------------------------------------------- We have a good amount of discussion and review in the goal document updates[7] and I have updated the patch by resolving the review comments. We will have policy popup meeting on 5 July[8]. 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[9]. Feel free to check and provide feedback. Zed cycle Leaderless projects ---------------------------------- No updates on this. Only Adjutant project is leaderless/maintainer-less. We will check Adjutant's the situation again on ML and hope Braden will be ready with their company side permission[10]. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[11][12]. Project updates ------------------- * None 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/847413 [3] https://review.opendev.org/c/openstack/governance/+/846890 [4] https://etherpad.opendev.org/p/tc-zed-tracker [5] https://review.opendev.org/q/projects:openstack/governance+status:open [6] https://review.opendev.org/c/openstack/governance-sigs/+/845336 [7] https://review.opendev.org/c/openstack/governance/+/847418 [8] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… [9] https://review.opendev.org/c/openstack/governance/+/836888 [10] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.ht… [11] https://etherpad.opendev.org/p/zuul-config-error-openstack [12] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028603.html [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann

1 0

[all][TC] Stats about rechecking patches without reason given
by Slawek Kaplonski 01 Jul '22

01 Jul '22

Hi, During the last PTG and after it, in the TC we were discussing about CI resources usage and about "rechecks" of the CI jobs (I know, it's again the same topic). One of the things we would like to limit, or even avoid is to do "no reason rechecks" which means writing quick comment "recheck" without checking what really was wrong in the previous run. We know that putting some hard rules that only comments with "recheck" with given reason will trigger new CI jobs run will not work fine as people may simply start writing any random things there. But we want to encourage all teams to at least to investigate failures and do as many rechecks with explanation as possible. For now I prepared simple script [1] which counts how much of all rechecks are "bare rechecks". It can be checked by project (like openstack/neutron) or give summary for all projects or teams (like Quality Assurance for example). I prepared some stats for all teams listed in the https://opendev.org/openstack/governance/src/branch/master/reference/projec… from last 30 days: +-------------------+---------------+--------------+-------------------+ | Team | Bare rechecks | All Rechecks | Bare rechecks [%] | +-------------------+---------------+--------------+-------------------+ | skyline | 20 | 20 | 100.0 | | magnum | 2 | 2 | 100.0 | | zun | 1 | 1 | 100.0 | | mistral | 9 | 9 | 100.0 | | ec2-api | 1 | 1 | 100.0 | | barbican | 15 | 15 | 100.0 | | venus | 2 | 2 | 100.0 | | solum | 1 | 1 | 100.0 | | tacker | 30 | 30 | 100.0 | | trove | 4 | 4 | 100.0 | | rally | 2 | 2 | 100.0 | | storlets | 5 | 5 | 100.0 | | winstackers | 3 | 3 | 100.0 | | OpenStack Charms | 32 | 33 | 96.97 | | sahara | 27 | 28 | 96.43 | | keystone | 24 | 25 | 96.0 | | kuryr | 120 | 126 | 95.24 | | kolla | 134 | 142 | 94.37 | | Puppet OpenStack | 94 | 103 | 91.26 | | cloudkitty | 10 | 11 | 90.91 | | OpenStack-Helm | 29 | 32 | 90.62 | | blazar | 8 | 9 | 88.89 | | tripleo | 563 | 646 | 87.15 | | requirements | 20 | 23 | 86.96 | | Telemetry | 30 | 35 | 85.71 | | horizon | 55 | 67 | 82.09 | | ironic | 131 | 164 | 79.88 | | oslo | 11 | 14 | 78.57 | | heat | 25 | 33 | 75.76 | | cinder | 221 | 294 | 75.17 | | cyborg | 6 | 8 | 75.0 | | murano | 3 | 4 | 75.0 | | glance | 20 | 27 | 74.07 | | OpenStackSDK | 47 | 64 | 73.44 | | manila | 108 | 160 | 67.5 | | neutron | 149 | 221 | 67.42 | | senlin | 2 | 3 | 66.67 | | swift | 16 | 25 | 64.0 | | Quality Assurance | 106 | 167 | 63.47 | | nova | 41 | 71 | 57.75 | | octavia | 32 | 60 | 53.33 | | designate | 19 | 39 | 48.72 | | OpenStackAnsible | 41 | 226 | 18.14 | +-------------------+---------------+--------------+-------------------+ As You can see from that list above, there is much to improve there. I hope that if teams will be checking more reasons of the CI failures, and reporting bugs found there, we may make our CI more stable and as a result have less rechecks which will save our infra resources :) [1] https://github.com/slawqo/rechecks-stats/blob/main/rechecks_stats/bare_rech… -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://opendev.org/openstack/governance/src/branch/master/reference/projec… [2] https://github.com/slawqo/rechecks-stats/blob/main/rechecks_stats/bare_rech…

8 10