June 2022 - openstack-discuss - lists.openstack.org

[large-scale][cinder] backend_native_threads_pool_size option with rbd backend
by Arnaud Morin 07 Jul '22

07 Jul '22

Hey all, Is there any recommendation on the number of threads to use when using RBD backend (option backend_native_threads_pool_size)? The doc is saying that 20 is the default but it should be increased, specially for the RBD driver, but up to which value? Is there anyone tuning this parameter in their openstack deployments? If yes, maybe we can add some recommendations on openstack large-scale doc about it? Cheers, Arnaud.

4 6

Re: Regarding Policy.json entries for glance image update not working for a user
by Adivya Singh 06 Jul '22

06 Jul '22

Hi Brian, Please find the response > 1> i am using Xena release version 24.0.1 > > Now the scenario is line below, my customer wants to have their login > access on setting up the properties of an image to the public. now what i > did is > > 1> i created a role in openstack using the admin credential name as "user" > 2> i assigned that user to a role user. > 3> i assigned those user to those project id, which they want to access as > a user role > > Then i went to Glance container which is controller by lxc and made a > policy.yaml file as below > > root@aio1-glance-container-724aa778:/etc/glance# cat policy.yaml > > "modify_image": "role:user" > > then i went to utility container and try to set the properties of a image > using openstack command > > openstack image set --public <image id> > > and then i got this error > > HTTP 403 Forbidden: You are not authorized to complete publicize_image > action. > > Even when i am trying the upload image with this user , i get the above > error only > > export OS_ENDPOINT_TYPE=internalURL > export OS_INTERFACE=internalURL > export OS_USERNAME=adsingh > export OS_PASSWORD='adsingh' > export OS_PROJECT_NAME=adsingh > export OS_TENANT_NAME=adsingh > export OS_AUTH_TYPE=password > export OS_AUTH_URL=https://<Internal IP of horizon>:5000/v3 > export OS_NO_CACHE=1 > export OS_USER_DOMAIN_NAME=Default > export OS_PROJECT_DOMAIN_NAME=Default > export OS_REGION_NAME=RegionOne > > Regards > Adivya Singh > > > > > On Mon, Jun 13, 2022 at 6:41 PM Alan Bishop <abishop(a)redhat.com> wrote: > >> >> >> On Mon, Jun 13, 2022 at 6:00 AM Brian Rosmaita < >> rosmaita.fossdev(a)gmail.com> wrote: >> >>> On 6/13/22 8:29 AM, Adivya Singh wrote: >>> > hi Team, >>> > >>> > Any thoughts on this >>> >>> H Adivya, >>> >>> Please supply some more information, for example: >>> >>> - which openstack release you are using >>> - the full API request you are making to modify the image >>> - the full API response you receive >>> - whether the user with "role:user" is in the same project that owns the >>> image >>> - debug level log extract for this call if you have it >>> - anything else that could be relevant, for example, have you modified >>> any other policies, and if so, what values are you using now? >>> >> >> Also bear in mind that the default policy_file name is "policy.yaml" (not >> .json). You either >> need to provide a policy.yaml file, or override the policy_file setting >> if you really want to >> use policy.json. >> >> Alan >> >> cheers, >>> brian >>> >>> > >>> > Regards >>> > Adivya Singh >>> > >>> > On Sat, Jun 11, 2022 at 12:40 AM Adivya Singh <adivya1.singh(a)gmail.com >>> > <mailto:adivya1.singh@gmail.com>> wrote: >>> > >>> > Hi Team, >>> > >>> > I have a use case where I have to give a user restriction on >>> > updating the image properties as a member. >>> > >>> > I have created a policy Json file and give the modify_image rule to >>> > the particular role, but still it is not working >>> > >>> > "modify_image": "role:user", This role is created in OpenStack. >>> > >>> > but still it is failing while updating properties with a >>> > particular user assigned to a role as "access denied" and >>> > unauthorized access >>> > >>> > Regards >>> > Adivya Singh >>> > >>> >>> >>>

3 5

[Octavia] Proposing Tom Weininger as core reviewer
by Gregory Thiemonge 06 Jul '22

06 Jul '22

Hi Folks, I would like to propose Tom Weininger as a core reviewer for the Octavia project. Since he joined the project, Tom has been a major contributor to Octavia, and he is an excellent reviewer. Please send your feedback in this thread, if there is no objection until next week, we will add him to the list of core reviewers. Thanks Gregory

4 4

[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

[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

[Openstack--Ansible] Playbook for Host Prep
by Dave Hall 30 Jun '22

30 Jun '22

Hello, I am wondering if there is any sort of playbook or script for setting up the networking on a new physical host prior to adding it to a cluster. It is a bit cumbersome to do it by hand, especially given that bridges on one type of host need an IP while the same bridge on another type of host should not have an IP. Seeding the /etc/hosts file would be nice as well. Going a bit further, it would be awfully nice if a given host could have the same 4th octet for all host interfaces, or at least for the important ones. I believe that since the 172.29 subnets are /22 this should be possible at least for smaller clusters. Thanks. -Dave -- Dave Hall Binghamton University kdhall(a)binghamton.edu

3 2

[sdk] renaming a volume with the SDK
by jdratlif＠globalnoc.iu.edu 30 Jun '22

30 Jun '22

I'm trying to set a property on a volume, specifically the name. But when I try to do this, it tells me the Session object has no default_microversion. I have all my auth in environment variables. Using TOKEN authentication. What am I doing wrong here? import openstack from openstack.block_storage.v3._proxy import Proxy as BlockStorageService from openstack.block_storage.v3.volume import Volume # enable openstack debug logging openstack.enable_logging(debug=True) conn = openstack.connect() cinder: BlockStorageService = conn.block_storage volume: Volume = cinder.get_volume("b3a70014-1cf0-4fd1-bdc4-183dbfd33e79") volume.name = "test_rename" volume.commit(conn.session) Thanks, --- John Ratliff Systems Automation Engineer GlobalNOC @ Indiana University

2 3

[neutron] Drivers meeting agenda - 01.07.2022.
by Lajos Katona 30 Jun '22

30 Jun '22

Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. * [RFE] Adding the "rekey" parameter to the api for strongswan like "dpd_action" (#link https://bugs.launchpad.net/neutron/+bug/1979044) * [RFE] Firewall Group Ordering on Port Association (#link https://bugs.launchpad.net/neutron/+bug/1979816) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda See you at the meeting tomorrow. Lajos Katona (lajoskatona)

1 0

[all][tc] Technical Committee next weekly meeting on 30 June 2022 at 1500 UTC
by Ghanshyam Mann 29 Jun '22

29 Jun '22

Hello Everyone, The technical Committee's next weekly meeting is scheduled for 30 June 2022, at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, 29 June at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[tc][policy][ptl][operator] OpenSatck RBAC goal is to focus on project personas first (postpone the 'scope' implementation)
by Ghanshyam Mann 29 Jun '22

29 Jun '22

Hello Everyone, We have received a good amount of feedback from the operator. In ops meetup Berlin as well as from KDDI (Japanese telco). I have summarized the feedback in etherpad[1]. From feedback, it is clear that 'scope' enable will break heat so do NFV operators and even other operators are also confused with the 'scope' concept. Most operators want legacy admin to work as it is (able to do everything in deployment). We discussed this feedback in the policy popup meeting[2] and based on feedback and our outstanding issue of 'scope enable break heat create_stack', we decided to postpone the `scope` implementation. That is the way forward to at least implement the project personas which is asked by many operators. Basically the below direction: * Finish delivering project personas This is to introduce the `member` and `reader` roles to operate things within their project. By default, any other project role like `foo` will not be allowed to do anything in the project. * Postpone the `scope` implementation for later Some standalone services like Ironic can still have the `scope` implementation as long as it does not break any cross-service communication. Other services will make sure they work for project scope personas even with enforce_scope enabled. We are not saying 'scope' things are not good or we will never do it but at the same time, I am not sure when we will do it in future. At least moving this giant goal to focus on the project personas first will help us to deliver one good feature (project personas) for operators otherwise we are stuck. Complete details about the reason to postpone the 'scope' implementation and projects persons detail are proposed in community-wide goal, please review there. - https://review.opendev.org/c/openstack/governance/+/847418 [1] https://etherpad.opendev.org/p/rbac-operator-feedback#L45 [2] https://etherpad.opendev.org/p/rbac-zed-ptg#L171

4 5